Field
This disclosure relates to video networks.
Description of Related Art
The background description provided here is for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent that it is described in the background section, as well as aspects of the description which may not otherwise qualify as prior art at the time of filing, are neither expressly nor implicitly admitted as prior art against the present disclosure.
Carrying video data over a packetised data network, such as an Ethernet network, involves dividing the video data into data packets, conveying the packets from a source device to a destination device, and reassembling the packets into a version of the original video data.
In a studio environment, or another part of a video production environment, there are constraints which go beyond the simple requirement to rebuild the original data stream at the destination device. These additional constraints relate to (i) the volume of data, (ii) the need to retain time synchronisation at the destination devices between received data from multiple sources, regardless of delays suffered during packet routing, and (iii) the need to send data from multiple sources to multiple destinations.
In terms of the volume of data, a video production environment typically requires frame-specific editing, which means that each individual frame must be capable of being reconstructed from the video data independently of any other video frame. This means that so-called long GOP video data compression techniques, in which some frames are derived from the decoded data for other frames, are not used. Also, in this type of environment, image quality is often considered a priority, which again means that each frame is represented by a relatively high quantity of data compared to other compressed video streams.
Time synchronisation is particularly important in a studio or video production environment, to allow a final video programme to be assembled from multiple video sources. If the signals from the multiple sources are not time-synchronised then some transitions from one source to another (such as slow fades) may be impossible, and in other transitions there can be subjectively disturbing image artefacts at a transition. In a previously proposed arrangement, the need for time synchronisation is dealt with by the combined measures of: time synchronising the source devices; arranging the network links to have a relatively short length (for example, a few hundred metres or at most a few km, rather than anything longer than a few km); and providing a variable delay element at each destination device so as to resynchronise the received data to a common time synchronisation. In a typical example, it has been found that a variable delay equivalent to just a few video lines (for example, 5 video lines) is sufficient to cater for the variations in packet transmission time over this type of network.
Before network-based video transmission was introduced, a typical video studio may have used circuit-switched video distribution, for example under the SDI (serial digital interface) protocol, in which a cross point switch allowed any source of video data to be connected to any destination device (or any selection of multiple destination devices simultaneously). In a previous proposal, such an arrangement can be provided under a packet-switched network by providing packets launched onto the network by the video data sources with so-called multicast group identifiers. A multicast group is an arrangement within a packet based data network such that any destination device can receive data packets carrying a particular multicast group identifier by the destination device “joining” that multicast group. Joining a multicast group involves a simple operation by the destination device and causes the packet router(s) to direct packets having that multicast group identifier to that destination device. So, by arranging for packets from the video data sources to be associated with respective multicast group identifiers, the operation of the circuit switched cross point witch can be mimicked in a packet based system in that any destination device can receive data from any source just by joining that particular multicast group. Similarly, multiple destination devices can receive data from a single source by all joining that multicast group. In practice, a multicasting system may be provided by (a) the data source setting—as a destination address for packets from that data source (relating to that multicast group)—one of a reserved set of IP addresses which are specifically reserved for indicating multicast groups, and (b) a data destination connects to that particular IP address so as to receive data from that IP address. The data destination may use a so-called “IGMP” message (discussed further below) to initiate the receipt of data from the multicast IP address. By this arrangement, the data source does not know (and does not need to know) anything about the data destinations, if any, which are receiving data relating to the multicast group. Similarly, the data destinations do not know (and do not need to know) where the multicast data originates. The multicast group mechanism simply provides a technique for transferring data from one data source to (potentially) multiple data destinations. So, the multicast IP address to which a data source sends data may be considered as a multicast group identifier relating to that source. (For completeness, note that another multicast mechanism also exists, namely “Source Specific Multicast” (SSM) in which the multicast group is identified not only by the multicast IP address but also by the IP address of the source itself. But the same principles apply. In respect of the description which follows, either multicast mode of operation is equally applicable to the present technology).
A feature of this arrangement is that the switching and routing of data packets at the network and transport layers uses standard techniques common to other data networks. Because the data destinations do not know where the multicast data originates from (because all they need to know in order to establish a connection is the multicast IP address), a main overhead in providing this simulated circuit-switched capability is just the need to assign individual multicast group addresses (or identifiers) to each source device (for example, one such address or identifier for each individual stream (video, audio and control) for a source device) and to communicate those identifiers in some manner to the destination devices to allow (or cause) the destination devices to join the appropriate group(s) to allow the destination device to receive the desired data stream(s). In one previously proposed arrangement, this is handled by a controller having a graphical user interface (GUI) which mimics the layout and control of a cross point switch, so that from the user's point of view, the user is simply setting up a route (on a virtual cross point switch) from source A to destination B, and the logic underlying the GUI carries out the appropriate selections of multicast groups and issues appropriate instructions to the destination device B.